Impulse II is a high-level application control system for RISC OS. It allows messages to be sent from one task to another. The conversing tasks may be running on different machines if you are attached to a network.
The messages contain simple textual commands and are very flexible in their application. This brings the ability to use powerful application programs in new ways.
Impulse II is public domain and we would like to see Impulse become established as the RISCáOS inter-application communication standard.
Objectives
It is intended that Impulse commands will allow control over applications in a huge variety of ways. They might be used to extract data from fields or cells, force calculations to take place, create new documents, force media updates, start activities such as printing, control access to data, transmit data to other applications, etc, etc. This can provide facilities from the very simple (eg informing all applications that a new font has appeared), through mid level interactions (eg mail merging a database into a DTP document) up to the very advanced (eg a document driven front end giving combined control over multiple applications simultaneously). Impulse commands are also ideally suited to such things as providing 'hot links' between spreadsheet and graphics packages.
A good example is implemented in the combination of Impression (Computer Concepts' RISC OS DTP/Wordprocessor) and MultiStore (Minerva Software's RISC OS Database Manager). These two applications are able to communicate via Impulse to provide full mail merge facilities. To do this, Impression allows Impulse commands to be embedded in the text of a document and expects these commands to retrieve data from another application (ie an Impulse server). The retrieved data may then be formatted into the document prior to printing. MultiStore understands suitable commands and can thus send data to Impression on request. In turn, Impression understands commands telling it to retrieve the required data and print the resulting document. MultiStore supports this by allowing a set of Impulse commands to be executed once for each record in a database. The end result is that, for each record in a database, MultiStore sends a command to Impression telling it to retrieve data and print it whereupon Impression requests the data from MultiStore, inserts it in its document, and prints it out. This results in one copy of the document for each record in the database, each with, say, a different name and address.
There are several points to note about the process described in the above example: It may be perceived that Impulse has effectively provided MultiStore with a sophisticated printing ability; alternatively, Impulse may be considered to have provided Impression with a sophisticated database management facility. Also, remember the previous comments about networks; it is possible that the MultiStore providing the database is running on one machine while the Impression doing the printing is on another (possibly half way round the world!). Finally, note that the Impulse commands used can be inserted into the Impression document and the MultiStore Impulse window by the user; this means that, with no change to the software, Impression can be just as easily linked to a different database and MultiStore to a different wordprocessor etc. Better yet, several applications might be linked allowing (eg) Impression to print a mail merge of data from many different sources.
How to do it
So how is all this achieved? Once you are running applications which can send and receive Impulse commands (ie Impulse Servers), you just need to know what commands (or Methods) are supported by each server and what the syntax of these commands is. There are standards of documentation (for describing the commands supported by each server) and standards of design (to ensure a degree of similarity between different Impulse commands and servers). This all helps to make life easier. Most servers will be supplied with examples to demonstrate their use and many will have been designed with a specific task in mind (eg the mail merge between MultiStore and Impression). However, don't let this restrict you! Impulse is a very flexible system and there will always be new applications to be discovered for existing servers.
Command syntax
All Impulse command strings have the same basic syntax regardless of the program you are trying to control. This is:
:ObjectPath MethodName Parameters
An object path specifies which server is to execute the command, where the server is and which of the objects it knows about should be acted upon. The method name is any method (or command) understood by that server. The parameters can be anything, depending on the method and the server. Reference to the documentation for the server will be necessary to determine valid method names and the possible parameters for them. The components of Impulse commands are described in more detail below.
ObjectPaths
ObjectPaths are paths from the current machine to the object on which the method is to be performed. If the first Identitifer in the ObjectPath matches the name of another machine on your network, Impulse will send the message to that machine. If the first Identifier in the ObjectPath does not match the name of another machine Impulse assumes that the path specifies an object on the local machine. You can force Impulse to look for objects on the local machine only by placing "$." at the start of the path.
Some example ObjectPaths are as follows:
Impression.MergeLet This object path can have two meanings. It either specifies document "MergeLet" in application "Impression" on the local machine, or if the local machine is connected to another called "Impression", the commad will be sent to an application called "MergeLet" on that machine!
$.Paint5 Specifies application "Paint5" on the local machine.
Fred.MultiStore.Users If the local machine is connected to another named "Fred" then this path specifies document "Users" in application "MultiStore" on machine "Fred".
Obviously, if the machine is not connected to any others the $ symbol doesn't need to be used at all! The ObjectPath is not always needed in command strings. Some commands may be broadcast to all applications on a machine, when it can be ommitted.
Methods
The operations that servers can perform on behalf of the client (ie the commands that each program understands) are called methods. Servers give their methods textual names to be used in command strings. The Impulse module decodes commands for the server telling it which method is being called but it is the responsibility of the server to extract parameters from commands. The commands are intended to be entered by ordinary users, not programmers, and so their design is very simple. The method names attempt to describe what they do.
Parameters
The parameters for different methods are dependent entirely on the servers supplying the methods. Each method may or may not need parameters of various types. Reference should be made to the documentation supplied with the server to determine exactly what commands are available.
Examples
Some example command strings that might be constructed for Impulse now follow:
:$.Impression.Letter23 DoMerge
Instructs the server called "Impression" on the local machine to execute the command "DoMerge" on the document "Letter23"
:Impression.Letter23 Edit Off
Instructs the server called "Impression" on the local machine to execute the command "Edit" on the document "Letter23" using the parameter "Off"
:$.MultiStore.Customers GetField @Name
Instructs the server called "MultiStore" on the local machine to execute the command "GetField" on the document "Customers" using the parameter "@name." Note that there is no basic difference between this command and the prceeding ones, even though we might expect this command to return some data. The returned data may or may not be used, depending on where the command is used. It is the users responsibility to make sure the command is put somewhere where returned data is expected (eg in a merge field in an Impression document).
FontDirChanged
Instructs the all servers to execute the command "FontDirChanged" with no parameters.
Remote method calls
As described above the ObjectPaths allow for the message to be sent off the local machine to other machines connected to it. This is made possible by tasks called Link Servers which register themselves with Impulse in the normal way. Each one controls the hardware/software link between the local machine and one or more other machines.
For example, consider the Econet link server. It might register itself to Impulse with the name öEconetò, so any ObjectPath which starts ö:Econet.ò will be sent to the Econet link server. The message will be sent on the network to the machine specified by the unresolved part of the ObjectPath. When the message is received from the network by the link server on the receiving machine, it adjusts the message before sending it on that machine.
Note that if a message has been transferred over one network to a machine which is connected to another the ObjectPath in the message could cause the message to be sent on the second network. Thus the machine connected to both networks automatically becomes a gateway between them for Impulse messages without any special ögatewayò software being used.
Example:
:Net.PhoneLink.Egypt.MultiStore GetField @Rate
Instructs the server called "MultiStore" via the "Net" link to the "PhoneLink" server through its object called "Egypt," to execute the command "GetField" using the parameter "@Rate."
Documentation
Any Impulse server will say in its documentation what its server name is and what methods it understands. This information will be repeated in a file called !IHelp inside the application directory. There is a standard for describing the syntax of Impulse II commands:
Parameters to be inserted are enclosed in angle brackets, <like this>. Optional parameters are also enclosed in square brackets, [like this]. Thus the syntax might be given as:
GetTimeDate [<format string>]
This means that there is one parameter called "format string" (rather than two, called "format" and "string"), and it is optional.
Each command will be followed by a piece of text describing the meaning of each of the parameters. If the method is likely to result in data being returned (as the above example might be), this will also be described. It is up to the user, or to Impulse Driver applications, to use such commands in places where the returned data are meaningful.
Terminology
Application A task which displays windows, icons and menus to communicate with the user.
Class The name of a group of objects which all respond to the same methods in the same way.
Client A task which requests another one to do something for it.
Conversation A sequence of one or more messages passed between two tasks. A conversation is always started when an Impulse command is used.
Method An operation that can be performed on an object by a server, ie the substance of an Impulse command.
Object A distinct entity owned by a server. Only the server which owns an object can do anything to the object. Examples are Impression documents, MultiStore databases.
Server A task which performs operations on objects at the request of other tasks. Examples are Impression and MultiStore.
Task A program running under the RISC OS Wimp, on the DeskTop.
